hey @taglia!
One concern about this pr: today we already have a lightweight cache via DriveItemRepository (SQLite), but it only caches the path -> uuid mapping. Every lookup still validates the item against the backend, so we never report a file or folder as existing unless the backend confirms it.

WebDavCacheService changes that behavior by serving cached metadata and directory listings for up to 2 minutes without any backend validation. Invalidation only happens for changes made through this same WebDAV instance, so changes from the web app, another device, or another CLI/WebDAV instance could leave us serving stale ("phantom") entries until the TTL expires. I think that's a regression compared to the current behavior.

My main concern is that as we need to keep validating cache hits against the backend to guarantee correctness, I'm not sure this cache provides enough benefit over what we already have today. I'd like to hear your thoughts before deciding whether to merge this PR 🤔

Hi @larryrider,

Thanks, that makes sense. I agree that serving cached metadata/listings without backend validation can introduce phantom entries when Drive is modified outside this WebDAV instance.

Given that correctness trade-off, I do not think this PR should be merged as-is. The two other PRs cover the safer generic improvements, and I’ll retest performance with only those changes before deciding whether a narrower cache proposal is still useful.

If we revisit this, I’d constrain it to an approach that preserves backend validation semantics rather than returning authoritative cached entries.

I will close this and test probably next week, I have a large backup in progress now and Hyper Backup can only run one at a time.